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Technical Field 

The present invention relates to a system and method that facilitates e-commerce 
volume pricing. 

Background of the Invention 

The buying and selling of goods and services (collectively referred to as 
"products") has resulted in a vast array of costing schemes which are used to select the 
price at which such products are sold. 

One of the most common costing schemes which consumers encounter everyday 
is known as fixed pricing. According to this costing scheme, sellers set a fixed price for 
their products based on a past demand for the product and/or anticipated future demand. 
Buyers desiring to purchase products from the seller are each required to pay the same 
fixed price regardless of the number of products purchased. If a seller finds that the 
demand for a given product is greater or less than expected, the seller can later adjust the 
fixed price of the product to account for such findings. Although the fixed pricing 
provides a simple way for a seller to conduct business with multiple buyers, one 
drawback of this costing scheme is that it fails to reward buyers willing to purchase 
greater quantities of products. 

Another common costing scheme for pricing a product is an auction. In an 
auction, a seller sets an initial price for an item and then multiple buyers are given an 
opportunity to bid against each other for the product. The buyer having placed the 
highest bid for the product at the end of the auction purchases the product at the final 
price bid. Although auctions provide advantages when selling unique products for which 
customers are willing to competitively bid, the auction forum is not well suited for sellers 
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desiring to sell large quantities of goods to multiple buyers given the inherent 
inefficiencies involved with selling one product at a time in a bidding environment. 

Yet another costing scheme, which has been advanced in recent years, is buyer- 
driven bidding. According to this costing scheme, a single buyer desiring to obtain a 
product communicates a price at which the buyer is willing to purchase the product to 
multiple sellers. Each of the sellers is provided an opportunity to review the buyer's 
price. A sale is complete when one of the sellers agrees to sell the product to the buyer at 
the price suggested by the buyer. While the buyer-driven bidding scheme provides 
advantages for certain types of transactions when, for example, sellers may be willing to 
sell products at lower than normal prices, the uncertainties involved with whether a 
buyer's offer will be accepted is often problematic for high volume commercial 
transactions in which the reliability that a transaction will be complete is of paramount 
importance. 

While the costing schemes described above have various advantages and 
disadvantages in different situations, a commonality among all of the costing schemes is 
that each buyer operates independently with one or more sellers to set a purchase price of 
a product in low volume transactions. Accordingly, there is a strong need in the art for a 
volume costing scheme which overcomes the above-mentioned drawbacks and others. 

Summary of the Invention 

The following presents a simplified summary of the invention in order to provide 
a basic understanding of some aspects of the invention. This summary is not an extensive 
overview of the invention. It is intended to neither identify key or critical elements of the 
invention nor delineate the scope of the invention. Its sole purpose is to present some 
concepts of the invention in a simplified form as a prelude to the more detailed 
description that is presented later. 

According to one aspect of the present invention, a system and method that 
facilitates e-commerce volume pricing is provided. The e-commerce volume pricing 
system and methodology is structured to provide incentive for buyers to work together 
when purchasing products. By working together, buyers are able to take advantage of 
lower pricing due to quantity discounts. To facilitate buying and selling products using 
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the e-commerce volume pricing system and methodology, an electronic forum is 
provided whereby buyers and sellers are able to conveniently exchange information and 
order products. 

Thus, according to one aspect of the present invention, system for facilitating 
volume pricing is provided. The system includes an offers and orders component that 
receives and aggregates orders for a product from a plurality of buyers. The system also 
includes a logistics component that determines a shipping price for the product for a 
subset of the plurality of buyers. The shipping price is determined at least in part upon 
the subset of buyers sharing a shipping method. 

In accordance with yet another aspect of the present invention, a method of 
costing is provided. The method includes electronically offering a product for sale, 
receiving a first order for the product from a first set of buyers at a first price, and 
receiving a second order for the product from a second set of buyers at a second price. A 
total quantity of products ordered from the first set of buyers and the second set of buyers 
is calculated and the first order is filled at a third price and the second order is filled at a 
fourth price, the third and fourth prices being based upon the total quantity of products 
ordered. 

In accordance with another aspect of the present invention, a method of costing is 
provided. The method includes electronically offering a product for sale by a seller and 
receiving orders for the product from a plurality of buyers. A final price is determined 
for the product based upon the total quantity of products ordered from the plurality of 
buyers and the final price is then compared to a contract price between the seller and at 
least one of the plurality of buyers. If the final price is less than the contract price, the 
orders are filled for all of the plurality of buyers at the final price. However, if the final 
price is greater than the contract price, the orders for the at least one of the plurality of 
buyers is filled at the contract price and the orders for the other of the plurality of buyers 
is filled at the final price. 

In accordance with yet another aspect of the present invention, a method of 
costing is provided. The method includes electronically offering a product for sale, 
receiving a first order for the product from a first set of buyers at a first price, and 
receiving a second order for the product from a second set of buyers at a second price. 
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Third and fourth prices are determined for the first set of buyer and the second set of 
buyers, respectively, based upon the total quantity of products ordered. It is then 
determined whether the third price is less than a contract price between a seller and at 
least one of the first set of buyers. If the third price is not less than the contract price, the 
orders are filled for at least one of the first set of buyers at the contract price, the other of 
the first set of buyers at the third price, and the second set of buyers at the fourth price. 
Otherwise, the orders are filled at the third price for the first set of buyers and at the 
fourth price for the second set of buyers. 

In accordance with yet another aspect of the present invention a volume pricing 
system is provided which includes a server configured to receive orders for a product 
from a plurality of different buyers via at least one remote computer system. The server 
includes a processor, a memory coupled to the processor, and a network interface coupled 
to the processor for transmitting and receiving data with the at least one remote computer 
system. The memory is utilized to store a first price schedule and a second price 
schedule, the first price schedule operable to determine a first price for the product for at 
least one of the plurality of different buyers and the second price schedule operable to 
determine a second price for the product for the other plurality of different buyers. 

In accordance with another aspect of the present invention, a method of costing is 
provided. The method includes electronically offering a product for sale in accordance 
with a price schedule, the price schedule setting a price for the product which varies in 
accordance with a quantity of the product ordered and receiving orders for the product 
from a plurality of different buyers. The total quantity of products ordered from the 
plurality of different buyers is calculated. A shipping price is then determined from at 
least one of the plurality of different buyers sharing a shipping method with at least 
another of the plurality of different buyers. A final price for the product is determined 
from the price schedule based on the total quantity of products ordered and the 
determined shipping price and the orders are filled for the plurality of different buyers at 
the final price. 

In accordance with another aspect of the present invention, a data packet is 
provided. The data packet is adapted to be transmitted between two or more computer 
processes and includes, one or more first fields adapted to store at least one pricing 
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structure for a product, one or more second fields adapted to store orders from a plurality 
of buyers for the product, and one or more third fields adapted to store a final price for the 
product based upon the total quantity of products ordered from the plurality of buyers or 
a Not To Exceed (NTE) contract price between the seller and at least one of the plurality 
of buyers. 

To the accomplishment of the foregoing and related ends, the invention then, 
comprises the features hereinafter fully described and particularly pointed out in the 
claims. The following description and the annexed drawings set forth in detail certain 
illustrative aspects of the invention. These aspects are indicative, however, of but a few 
of the various ways in which the principles of the invention may be employed and the 
present invention is intended to include all such aspects and their equivalents. Other 
objects, advantages and novel features of the invention will become apparent from the 
following detailed description of the invention when considered in conjunction with the 
drawings. 

Brief Description of the Drawings 

In the annexed drawings: 

Fig. 1 illustrates a diagrammatic view of a system for electronically conducting 
business in accordance with one aspect of the present invention; 

Fig. 2 illustrates a flow diagram for facilitating e-commerce volume pricing in 
accordance with one aspect of the present invention; 

Fig. 3 illustrates a flow diagram for linking deal rooms in accordance with one 
aspect of the present invention; 

Fig. 4 illustrates a web page providing options to buyers and sellers desiring to 
conduct business electronically in accordance with one aspect of the present invention; 

Fig. 5 illustrates a web page providing options to buyers desiring to conduct 
business electronically in accordance with one aspect of the present invention; 

Fig. 6 illustrates a web page in which details for a product are displayed in 
accordance with one aspect of the present invention; 

Fig. 7 illustrates a deal room in which buyers may place electronic orders for 
products posted by sellers in accordance with one aspect of the present invention; 



GEDP101USE 



Fig. 8 illustrates a web page for a buyer to place an order for a product in 
accordance with one aspect of the present invention; 

Fig. 9 illustrates a continuation of the web page in Fig. 6 in accordance with one 
aspect of the present invention; 

Fig. 10 illustrates an on-line registration form for a buyer in accordance with one 
aspect of the present invention; 

Fig. 1 1 illustrates a seller sponsored transaction in accordance with one aspect of 
the present invention; 

Fig. 12 illustrates a buyer sponsored transaction in accordance with one aspect of 
the present invention; 

Fig. 13 illustrates a multiple buyer and multiple seller sponsored transaction in 
accordance with one aspect of the present invention; 

Fig. 14 illustrates a web page in which buyers and sellers may customize in 
accordance with one aspect of the present invention; and 

Fig. 1 5 illustrates a block diagram of a central server in accordance with one 
aspect of the present invention. 

Detailed Description of the Invention 

The present invention is now described with reference to the drawings, wherein 
like reference numerals are used to refer to like elements throughout. In the following 
description, for purposes of explanation, numerous specific details are set forth in order 
to provide a thorough understanding of the present invention. It may be evident, 
however, that the present invention may be practiced without these specific details. In 
other instances, well-known structures and devices are shown in block form in order to 
facilitate describing the present invention. 

Referring initially to Fig. 1, a system 10 is shown in which multiple buyers 15 and 
sellers 20 are electronically linked via a central server 25. As discussed in more detail 
below, the central server 25 is configured to provide the buyers 1 5 and sellers 20 with a 
convenient forum in which to buy and sell goods in accordance with a volume pricing 
methodology described herein. The forum can, for example, be an established Internet 
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web page where sellers 20 are able to post product information and the buyers 1 5 are able 
to order the products. 

Each of the buyers 1 5 and sellers 20 can access the central server 25 in any of a 
variety of ways. For example, each buyer 1 5 and seller 20 is shown to be part of separate 
establishments 30 which include one or more respective computer systems 35 and local 
servers 40. The computer systems 35 can, for example, be a desktop or laptop computer 
with a local area network (LAN) interface for communicating over a network backbone 
45 to the local server 40. The local servers 40, in turn, interface with the central server 
25 via a network cable 50 or the like. It will be appreciated that while the computer 
system 35 is depicted as communicating with the central server 25 via hardwired network 
connections, alternatively, the computer system 35 can interface with the central server 
25 using a modem, wireless local area and/or wide area networks, etc. Further, it will be 
appreciated, that while the buyers 1 5 and sellers 20 are shown to communicate with the 
central server 25 via different computer systems 35, it will be appreciated that the buyers 
1 5 and/or sellers 20 can access the central server 25 from the same computer system 25. 

As used in this application, the terms "component" and "module" are intended to 
refer to a computer-related entity, either hardware, a combination of hardware and 
software, software, or software in execution. For example, a component and/or module 
may be, but is not limited to, a process running on a processor, a processor, an object, an 
executable, a thread of execution, a program, and a computer. By way of illustration, 
both an application running on a server and the server can be a component and/or 
module. 

The underlying architecture of the software system used to provide buyers and 
sellers with a forum for conducting business is created as a collection of components. 
Component-based architecture allows separate sections of code to stand alone from one 
another, thus allowing for easier replacement, debugging, removal, updating, etc. 
Components also allow multiple users to work independently on separate components 
without interference from other components. For example, a component could be 
reprogrammed to enhance its speed without necessitating the recoding of half of the 
system as might be required in a non-component based system. Furthermore, custom 
components can be developed for specific customers based upon the requirements of the 
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customers. Such components can be further customized to interact directly with the 
customers' systems. The component-based system also has the ability to recognize when 
two or more users are simultaneously making changes to a component or module. Thus, 
the system can accommodate for the simultaneous changes to mitigate any problems that 
might occur. For example, a locking or change comparison process can prevent a first 
user from writing over new data, entered by a second user, with old data. 

The kernel component is the central component in the operating system. 
Typically, the kernel is responsible for memory management, process and task 
management, and disk management. In the present invention, the kernel component is 
divided into twelve functional modules. However, it is to be appreciated that the number 
of modules is not essential to the invention. Thus, a kernel containing more or less than 
twelve modules, which performs the functions as described herein, is contemplated as 
falling within the scope of the present invention. 

The first module is an offers and orders module, which manages the offers and 
orders for products, such as posting, processing, storing, etc. The second module is a 
catalog module, which manages seller catalogs, product categories, and products. The 
third module is a users and groups module. This module allows for the storage, creation, 
editing, and deletion of users and groups and will generally be used by the deal rooms. 
The fourth module, an access control module, is responsible for enabling users and 
groups to see what they have been authorized to see and similarly, perform the tasks that 
they have been authorized to perform. 

The fifth module is a messaging module, which allows various module functions 
to be invoked by the user interface and/or remote integrated systems. The messaging 
functionality may also be embedded into other modules. The sixth module is a terms and 
conditions module, which manages agreements between parties involved in each 
transaction, such as the terms and conditions agreed to between buyer and seller, buyer 
and system administrator, seller and system administrator, etc. The seventh module is a 
blanket pricing module. This module manages agreements between buyers and sellers as 
to product prices. The eighth module, a product relationships module, allows sellers to 
create relationships between related products. The ninth module is a logistics module, 
which allows for the management of the product shipment. A RFQ/RFO/RFP module 
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manages quote, offer, and product requests. The eleventh module is an invoicing 
module, which manages administrative functions, such as record keeping, invoicing, 
credit checks, etc. Finally, an agents module is used to automate routine tasks and/or to 
provide decision support and guidelines. 

Modules allow for greater flexibility and customization since they can be enabled 
or disabled for the entire system on a user-by-user, group-by-group, access point-by- 
access point basis. The purpose of allowing the enabling and disabling of modules is 
necessary because there may be some modules that a user does not require or is not 
licensed to use. Furthermore, modules may need to be disabled for maintenance, 
troubleshooting, or upgrading. Function enabling/disabling is designed to allow the 
system administrator or host to prevent user access to certain features. It is to be further 
noted that functions within one module can be dependent upon functions in another 
module. Thus, modules are able to communicate amongst each other. It is possible that 
modules may reside on separate servers, thus allowing the system to easily handle 
increases in volume. 

The offers and orders module contains the logic necessary to perform functions in 
relation to offers and orders, such as creating, storing, editing, and deleting. This module 
can also manage options, smart offers, shopping carts, multiple line item orders, derived 
offers, the offer finder, order approval, commit-at-price orders, quote generation, multiple 
line item quotes, discounts, gift certificates/merchandise credits, and other related 
functions. 

Offers are typically made to present product options to a buyer. Pricing for offers 
can be in terms of percent markup/markdown, flat fee/savings, fee-per-item/savings-per- 
item, or aggregate options. Two types of offers are available: single offers and aggregate 
offers. A single offer is one in which the final price of a product is determined by an 
individual buyer. The price can be dependent upon the volume of product that the 
individual buyer is purchasing or can be contractually negotiated between the seller and 
the individual buyer. On a single offer, once a final price has been determined and the 
individual buyer has placed an order, the offer is considered closed. However, it is 
possible for a buyer involved in a single offer transaction to benefit from an aggregate 
offer. For example, a buyer can require an earlier ship date than the date offered in the 
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aggregate offer, thus the buyer can request a single offer from the seller. If the seller can 
manufacture the products ordered in the single offer in the same lot as the products 
ordered in the aggregate order, the seller can pass on the cost benefits in the single offer 
as well as in the aggregate offer. 

An aggregate offer is one in which the final price of a product is determined by a 
plurality of buyers. The plurality of buyers can consist of individual buyers and/or 
purchasing groups. The plurality of buyers can place orders through an aggregation 
aware system, as described herein, as well as through a non-aggregation aware system. 
Generally, the net volume of product ordered by the plurality of buyers determines the 
final price of the product. A seller can provide a pricing structure/price curve or an 
equation to detail how the price of the product changes with the volume ordered. 
Additionally, or alternatively, the price of the product can change with respect to the time 
remaining on an open offer. For example, the seller can discount the product by 25% 
during the last five days of the offer or the price can be programmed to regularly drop by 
a percentage throughout the time period of the offer until a hidden price point is reached. 
Other factors which can affect the product pricing strategy include: market conditions, 
time remaining before shipment, the number of current orders on an offer, the quantity of 
product still available, and the number of buyers currently participating in the offer. 

The final price for the product is not calculated until the order close date, which 
can be extended by the seller up until the ship date. Thus, based on the cumulative orders 
received at the end of an "open session" period, a seller can provide all buyers with the 
same quantity discount for the product regardless of what the price of the product was at 
the time each buyer placed the order. Therefore, each buyer is able to benefit from other 
buyers ordering the same product since the cumulative orders received at the end of the 
open session determines the price for all buyers placing orders during the open session. 
If a buyer cancels an order or reduces the quantity of the order, the seller maintains the 
final aggregate price as to the rest of the buyers. Alternatively, the seller can specify in 
his terms and conditions that the seller preserves the right to change the pricing structure, 
which can, in some instances, hold the buyer to a higher price than the buyer had 
originally agreed to. If the buyer cancels in either of the aforementioned situations, the 
buyer can be subject to a cancellation or penalty fee at the discretion of the seller. In both 
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situations, when the buyer cancels or changes the order quantity, the cancelled or 
changed quantity can be immediately made available to the other buyers in the deal room. 

However, the final price determined at the close of an open session period will not 
necessarily be the same for each buyer or group of buyers that participated in the 
aggregate offer. For example, the buyer and seller can have an agreement in which the 
seller has agreed that the buyer will not pay above a certain amount, a NOT TO 
EXCEED (NTE) price, for a product or order. Thus, if the aggregate final price is greater 
than the contract price between the buyer and seller, the buyer will only pay the agreed 
upon NTE price. This NTE price can be contracted to be available to an individual order, 
a predetermined quantity of orders, or any orders placed within a particular time frame. 
The contract between the parties can further specify that the NTE price can change 
automatically based upon the length of the relationship between the parties and/or the 
amount of volume the buyer places with the seller over time. Moreover, an individual 
buyer's NTE price can remain in effect for the individual although the individual is 
ordering as a member of a purchasing group. 

Another instance in which the final price determined at the close of an aggregate 
offer can vary for each buyer or group of buyers is when one or more buyers take 
advantage of coupons and/or discounts offered by the seller. Such coupons and/or 
discounts can be applied to the aggregate final price, thus allowing the holder of the 
coupon and/or discount to receive a lower price than other buyers within the aggregate 
group. For example, a seller can award a discount to an individual buyer within a group 
for being the most significant contributor to the group's buying power. Thus, the final 
product price for the group is $4.00, but the price to the individual buyer within the group 
is $3.50. Coupons and/or discounts can take the form of a percentage off the final price, 
a pre-negotiated flat fee, step discount prices tied to volume, etc. Coupons and/or 
discounts will be given for a variety of reasons, such as: the length of the relationship 
between the buyer and seller; the order volume the buyer has placed with the seller; the 
seller's need to reduce inventory; the seller's need to sell product more rapidly; and any 
other reason desired by the seller. For example, if a buyer promises to buy product A 
from the seller exclusively for one year, the seller can afford the buyer a 5% discount off 
the final price. As an additional example, if a buyer registers to be part of a particular 
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purchasing group for the next six months, the seller can afford the buyer a 5% discount 
off the group price. 

Thus, according to one aspect of the present invention, a volume pricing 
methodology is shown with respect to Fig. 2. The method starts at 60 with a seller 
offering a product or a plurality of products for sale in a deal room during an open offer 
period. The seller applies a pricing curve to the product at 62 so that the price of the 
product decreases as more products are ordered. At 64, a plurality of buyers place orders 
for the product during the open offer period. The open offer period ends at 66. The end 
of the open offer period may be based upon a predetermined time, available quantity of 
the product, and/or the seller can choose to close the open offer period prematurely. At 
the end of the open offer period, a final price is calculated from the pricing curve and is 
based upon the total quantity of products ordered from all of the plurality of buyers (68). 

At 70, the system determines whether any of the plurality of buyers has a NTE 
price contract with the seller. If yes, at 72, the system determines whether the NTE price 
is lower than the calculated final price based upon the aggregation. If the NTE price is 
lower, the buyer(s) will receive the NTE price (74). If the NTE price is higher, the 
buyer(s) will receive the final aggregated price (76). If the buyers do not have a NTE 
price contract with the seller, the NTE price determination is skipped. At 78, the system 
determines whether the buyer is eligible to receive a coupon and/or discount from the 
seller. If yes, the coupon and/or discount are applied to the buyer's final price (80), the 
final price being either the calculated price based on the aggregation or the NTE price. 
Otherwise, no additional discount is given to the buyer(s) (82). Thus, although all the 
buyers are participating in an aggregated offer for the same product, the final price 
amongst the participating buyers can be different. 

Furthermore, buyers within an aggregate group can be subject to different pricing 
structures, or price curves, for the same product. For example, a seller can access 
information about the buyers past purchasing history, such as the number or percentage 
of cancelled orders, on-time payments, and/or the number of orders the particular buyer 
has placed through the system. This information can be viewed in terms of the buyer's 
history with that particular seller, all sellers, that particular product or product category, 
or all products. Based on these criteria, a ranking is assigned to the buyer either manually 
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or by default criteria set by the seller. This ranking can then determine the pricing 
structure that the buyer receives for a particular product. For instance, a buyer with a 
100% rate of taking receipt of all orders online and 100% of paying within 30 days would 
be assigned a high ranking of AA. When this buyer returned to the site and entered a 
password, the AA rating would be denoted and a certain pricing structure would be made 
available to that buyer for placing an aggregate order. Likewise, a buyer with a low CC 
ranking could see a pricing structure with a 5% premium, simply based on their password 
and past performance. Additionally, a buyer can be grouped into a specific pricing 
structure according to the buyer's current or historical product volume consumption. 
Generally, a buyer within an aggregate group will only have access to view the pricing 
structures applicable that individual buyer, and not to other buyers within the same group. 
Movement between groups is possible for individual buyers upon achieving different 
ratings and/or volume consumption. 

One method of achieving the aforementioned pricing strategy is shown with 
respect to Fig. 3 and involves a seller having two or more deal rooms with open offers for 
the same product. Deal rooms provide a convenient forum for sellers to receive orders 
from multiple buyers during an open session period and will be described in further detail 
later. Each individual deal room has a different pricing structure and only authorizes 
access to buyers meeting predetermined criteria specified by the seller. At 90, a seller 
opens two or more deal rooms, each deal room offering the same product, but having a 
different price curve. At 92, the seller structures each of these deal rooms so that the 
available capacity is shown in full in each of the deal rooms and is linked between the 
deal rooms. At 94, at least one buyer places an order in at least one of the deal rooms. 
Since the capacity is linked between the deal rooms, the available quantity of product 
falls by the ordered amount in each of the opened deal rooms (96). For example, a seller 
plans to produce 5000 pieces of product A. The seller opens deal room 1 and deal room 
2 and establishes both deal rooms as having 5000 pieces of product A available. If a 
buyer in deal room 1 purchases 1000 pieces of product A, both deal room 1 and deal 
room 2 show the available quantity of product A as 4000 pieces. Since the pricing 
structures within the different deal rooms are different, an order can reduce the price by 
10% in one deal room and by only 5% in another deal room. 
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Alternatively, the seller can divide the capacity between the two deal rooms. 
Thus, in the example above, if the seller plans to produce 5000 pieces of product A, the 
seller can configure both deal room 1 and deal room 2 with 2500 pieces of product A. 
Thus, if a buyer places an order for 1 000 pieces in deal room 1 , the available quantity in 
deal room 1 becomes 1 500 pieces, and the available quantity in deal room 2 remains at 
2500 pieces. However, buyers participating in both deal rooms are still afforded the 
advantage of the demand aggregation on 5000 pieces. Throughout the open offer period, 
the seller maintains the ability to modify various aspects of the offer as deemed 
necessary. In the last example, if the seller is receiving significantly more activity in deal 
room 1 than in deal room 2, the seller can reduce the available capacity in deal room 2 by 
1 500 pieces and add that 1 500 pieces to deal room 1 . Thus, changing the available 
quantity in deal room 1 to 3000 pieces and the available quantity in deal room 2 to 1000 
pieces. Similarly, the seller can opt to close deal room 2 prematurely and apply the entire 
available capacity to deal room 1 . Sellers are only limited in their modification rights to 
the extent that any of the buyers would be disadvantaged. Furthermore, any 
modifications made to a deal room is done in real time; thus, allowing buyers to view the 
most up to date information at any time. 

Two or more sellers of the same product can also utilize the aforementioned 
method of employing multiple deal rooms with multiple pricing structures. For example, 
both a manufacturer and a distributor can be engaged in selling the same products 
through the system. Since the manufacturer is supplying the distributor with the 
products, the manufacturer will realize production efficiencies in aggregating product 
volume between the both the manufacturer's deal rooms and the distributor's deal rooms. 
Thus, all parties involved in the transaction will realize cost benefits. 

Moreover, a manufacturer and a distributor of the same product can take 
advantage of an auto post feature in the system. This feature will immediately post an 
open offer in the distributor's deal room upon the manufacturer posting an open offer in 
the manufacturer's deal room. This process includes a distributor receiving a list of 
products that will be offered in the deal room by the manufacturer. This list is tagged by 
the distributor to have these products automatically populate in the distributor's deal 
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room along with the requisite lead-time (e.g., a three day difference) between the 
distributor's receipt of the product and the ship date posted to the buyers. 

The distributor can also specify the price breaks to be added above those provided 
by the manufacturer (i.e., a starting price of $65/1 000 pieces submitted by the 
manufacturer shows as 125% of that price/same volume to the distributor's customers). 
The figure applied can be a multiple (1 .25), a percentage (125%), set price ($85), etc. 
along with the requisite price breaks or a flat price and all other information. The system 
provides the benefit of automatically posting open offers downstream from one deal room 
to another. Likewise, there can be multiple segments within one deal room based on 
different customer segments. For example, upon a manufacturer posting an offer in a 
deal room, three different deal rooms can open for the distributor for three different 
groups of buyers. The first deal room can specify 125% of the manufacturer's price and 
a lead-time of three days from the manufacturer's ship date; the second deal room can 
specify 1 1 0% of the manufacturer's price and a lead-time of three days from the 
manufacturer's ship date; and the third deal room can specify 105% of the manufacturer's 
price and a lead-time of two days from the manufacturer's ship date. In addition, or in 
the alternative, other features can also be varied within the different deal rooms, such as 
pay options and product options. It is to be appreciated that the auto post feature can be 
used by a plurality of sellers with related products and is not limited to a manufacturer 
and distributor relationship. 

The feature described above can also work in the opposite direction with a 
distributor placing an order that triggers a single or aggregated offer from a manufacturer. 
For instance, a distributor in a family of regionally dispersed distributors has an order for 
1 0,000 units of a product that is needed in five weeks. The distributor can request this 
order be an aggregated offer posted to the rest of their divisions/deal room participants 
for aggregation. An open offer is triggered by this request with any price breaks that 
have been predetermined by the manufacturer. The manufacturer can have an automatic 
check feature, which can check if the offer is already posted and alert the distributor. The 
automatic check feature can also check to see whether the offer is within a time frame 
specified by the manufacturer, whether any options are included in the offer, whether 
capacity is available to post the offer. Furthermore, a message can be sent directly to the 
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manufacturer's messaging system for a confirmation request before it is posted as an 
open offer. 

Once this open offer is posted, it will automatically have the requested amount 
specified by the distributor baseloaded within the offer, and other distributors are notified 
of the purchasing opportunity. Another offer can automatically populate in the 
distributor's deal room for their buyers as well. Moreover, the manufacturer can request 
that another open offer be created in a different deal room at a different pricing structure. 
For example, a large distributor with access to the trigger functionality requests and posts 
automatically an aggregated offer from a supplier. This open offer is then baseloaded 
with the order and presented to the rest of the buyers within that section of the deal room. 
As more buyers order, the price drops accordingly. The trigger function automatically 
populates a second open offer to other deal rooms provided by the manufacturer. The 
pricing structures and quantities can be predetermined in the system and can be changed 
at any time. A confirmation function can be engaged which requests that the 
manufacturer validate the option of posting the offer in another deal room. 

Buyers also have the ability to rank the performance of any sellers with whom 
they have transacted. Sellers can be ranked on criteria such as, on-time delivery, quality 
of goods, communication, and response time to Requests for Quote (RFQ), Requests for 
Offers (RFO), and Requests for Product (RFP). Both buyers and sellers can allow other 
buyers and sellers to view their respective rankings. In addition, buyers and sellers are 
afforded the opportunity to leave feedback to a buyer or seller in response to a transaction 
between the parties. Such feedback can be available to the entire user community, thus 
affording a new buyer the opportunity to view a particular seller's on-time delivery 
history prior to placing an order with that seller. 

An aggregate offer can have a fixed minimum order quantity or a variable 
minimum order quantity. In an offer that contains a variable minimum order quantity, a 
seller can fluctuate the minimum quantity that an individual buyer must order as the total 
aggregate order changes. For example, an offer can be established to automatically 
decrease the minimum order quantity from 500 pieces to 100 pieces as soon as the total 
aggregate order quantity reaches 5000 pieces. Then again, an offer can be created in 
which no minimum order quantity is required; however, the seller retains the right to 
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cancel the entire order if the quantity does not reach a predetermined level by a specified 
date and time. Minimum order quantities can be specified per shipping location. This 
allows sellers to take advantage of shipping aggregation for different ship points. 

The system also has the ability to automatically suggest or create offers based on 
history or user specifications. These offers can be time or quantity dependent. For 
example, the system automatically opens an offer for a specified product every two 
weeks or every time 1 000 units of a product are ordered, the order closes and a new order 
for that product is opened. Offers can also be created automatically based upon a 
purchasing agreement between a buyer and seller for guaranteed acceptance of product 
orders throughout a predetermined time period. Thus, the seller can post planned 
inventory in advance. For example, if a buyer agrees to accept shipment of 1 00 racks of 
glass the first week of every month for the next six months, the seller then posts the 
availability of an additional 50 racks of the same glass for the same week. The original 
buyer provides a base that absorbs much of the fixed costs associated with the schedule 
while the incremental 50 racks represents proper capacity utilization at much higher 
profit margins. 

Buyers have the ability to create conditional orders for a product. Conditional 
orders are created, for example, when a buyer agrees to place an order if the price drops 
below a specified level or if the aggregation reaches a certain percentage discount. If, or 
when, the condition is met, the buyer's order will be automatically placed by the system. 
Furthermore, the system will recognize when two or more conditional orders can be 
combined to perfect the condition and thus, place these orders. For example, buyer 1 
wants to buy X units of a product if it falls below $5 and buyer 2 wants to buy Y units of 
the same product if it falls below $5. If quantity X plus quantity Y plus any quantity 
currently on order is enough to bring the price below $5, both buyer 1 's and buyer 2's 
orders will be placed. 

In view of the foregoing features described herein, exemplary web pages in 
accordance with various aspects of the present invention will be better appreciated with 
reference to Figs. 5-10. It is to be understood and appreciated that the present invention 
is not limited by the illustrated order of these web pages, as some aspects could, in 
accordance with the present invention, occur in different orders and/or concurrently with 
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other aspects from that shown and described herein. Moreover, not all illustrated 
features on the web pages may be required to achieve the advantages of the system in 
accordance with an aspect the present invention. 

Turning now to Fig. 4, an exemplary Internet web page 120, which provides 
buyers and sellers with access to a forum for conducting business, is shown. The web 
page 120 includes hyperlinks for handling both registered and un-registered buyers and 
sellers of products. For example, registered buyers can select a hyperlink to a registered 
buyer login screen via hyperlink 125 while non-registered buyers can select a hyperlink 
to a non-registered buyer registration screen via hyperlink 130. Similarly, registered 
sellers can select a hyperlink to a registered seller login screen via hyperlink 135, while 
non-registered sellers can select a hyperlink to a non-registered seller registration screen 
via hyperlink 140. While separate hyperlinks are shown for buyers and sellers, it will be 
appreciated that such hyperlinks could alternatively be combined and the status of buyer 
or seller could be determined during a later stage in the login procedure. 

Turning now to Fig. 5, in accordance with one aspect of the present invention, an 
exemplary product category web page 1 50 is shown. Included on this page is a category 
menu 1 55, comprising hyperlinks 1 60 to other product category web pages. The web 
page 150 also includes a general pull down menu 165, which allows a user to perform 
such functions as: find help on a particular topic; contact the seller and/or the web page 
host; update and/or view the user's profile, which includes details such as, the user's 
login name and password, company information, shipping information, billing 
information, and any special instructions; view past orders and/or current orders; view 
and/or edit the favorites menu; search for products, buyers, sellers, etc.; and log out of the 
system. The product categories menu 155 and the general menu 165 can be included on 
each web page for ease of navigation throughout the system. 

The product category page 150 includes the category name 170 and a brief 
description of the category 175. A list of the product's subcategories 1 80, if available, is 
shown with hyperlinks 1 85 to each of the product subcategory's pages (not shown). The 
product subcategory page is similar in structure and content to the product category page 
1 50. A section containing a summary of products available under the product category is 
shown. This section includes information such as, the name of the product 1 90, whether 
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the product has any open offers, aggregate 1 95 or single 200, how many open offers are 
available for each product, and a hyperlink 2 1 0 to the product details web page. If any 
open offers exist for this particular product category, a section with a summary of the 
open offers will be shown. This section can be split into a summary of the open single 
offers 2 1 5 and a summary of the open aggregate offers 220. This open offer summary 
includes information such as: the product name 225, a hyperlink 230 to an offer details 
web page, the shipping terms 235, the price 240, the shipping date 245, and a hyperlink 
250 to a seller sponsored deal room. Shipping terms are included in both single and 
aggregate offers and are typically Free On Board (FOB) terms. However, other shipping 
terms can be provided, such as FAS, CIF, C&F, or any other applicable shipping term. 
The hyperlink 250 to the supplier sponsored deal room allows a buyer to place an order in 
connection with one of the offers. 

The product categories menu 1 55 can also link the user to a catalog (not shown). 
The catalog can be viewed and arranged by product type, by seller, and/or by pricing. 
Sellers have the option of blocking access to any or all of their product listings from 
specified system users. Sellers can also create custom templates for ease of adding a new 
product listing. A default template is also available by the system host for this purpose. 
The product listings in the catalog contain details about each product, including the 
manufacturer/distributor, default pricing and/or price curve, any available options and/or 
customizations, minimum order quantities, ship terms and links to related products. The 
catalog can also be accessed through alternate means, such as the search function, the 
favorites menu, the user's homepage, etc. 

An example of a product details web page 260 is shown in Fig. 6. Here an image 
of the product 265 is shown along with details 270 that can be important to a buyer when 
determining whether to purchase the product. Included in these product details 270 are: 
the name of the seller, with a hyperlink 275 to a seller details page (not shown); the name 
of the manufacturer, if different from the seller, with a hyperlink 280 to a manufacturer 
details page (not shown); unit description 285 {e.g., pieces, feet, inches); and a 
description of the product 290, which can include details not readily apparent by the 
image shown. The seller details page and the manufacturer details page can include 
information such as: the name, address, and contact information of the seller and/or 
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manufacturer; other products available by the seller and/or manufacturer; feedback from 
other buyers and/or sellers; and any open offers currently available from the seller and/or 
manufacturer. Also included on the product details page is a 'View Open Offers' 
hyperlink 295 to view offer details of any open offers for the product and a 'View 
History' hyperlink 300 to product history web page (not shown). The product history 
page can show details and/or summaries of the product history, such as, when the product 
was introduced to the system, how many times the product has been ordered in the past, 
on what dates, and in what quantities, the average cost of the past orders, how many 
buyers participated in the offers, and when the next open offer is anticipated. A 'Create 
RFQ/RFO' hyperlink 305 is provided to direct buyers to a page, which will allow them to 
request a quote or offer for the product in the event that there are no open offers for a 
product or the current open offers do not meet the buyer's needs (e.g., shipping date, 
quantity, options). 

Turning now to Fig. 7, in accordance with one aspect of the present invention, 
deal rooms are set up in which buyers are able to view the details of an open offer and 
order products in connection with the open offer. The deal room includes the product 
name 315 and a hyperlink 320 to the product details web page. Also included in the deal 
room is an offer details section 325, which contains information such as: the offer 
number; the seller, with a hyperlink to the seller details page; the ship date or ship date 
range; the ship terms; quantity available; quantity sold; quantity on hold; minimum order 
quantity; ship increments; offer open date; offer close date; and any other additional 
information given by the seller. The minimum order quantity can be fixed or it can 
change with the current ordered volume against an offer. The pricing for this offer is 
displayed in both a graphical format 330 and a table format 335. The current price 340 
for the product, based upon the quantity of parts currently on order, is shown in real time. 
The current price is based on a base product without any custom options. If options are 
available for the product, they will be shown in an options section 345. In this example, 
options for product size and product color are offered. Any price increase or decrease is 
shown with respect to each option. For example, if the product has a standard blue 
coating, the option to have a yellow coating increases the cost to the buyer by $2 per 
1 000 pieces. However, if the buyer opts to order the product without any coating, the 
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cost decreases by $8 per 1000 pieces. Thus, a seller could configure the deal room to 
show different price curves for each of the different product options. Furthermore, 
different deal rooms for the same product can be configured to provide different available 
options for the different buying groups. 

Based on the above information, if a buyer desires to place an order, the buyer 
selects an 'order' icon 350, displayed within the deal room, to continue the purchasing 
process. Alternatively, if the buyer is interested in the offer, but does not yet wish to 
place an order, the buyers can select a 'watch this offer' hyperlink 355 displayed within 
the deal room. The offer can then appear on a web page, such as the buyer's homepage, 
in which all of the buyer's watched offers will be displayed. Moreover, the system can 
be prompted to notify the buyer of any activity that can occur with respect to that 
particular offer. Furthermore, if the buyer has any questions about the offer, the buyer 
can choose the 'contact seller' hyperlink 360. This hyperlink 360 will direct the buyer to 
the seller's email, or messaging, screen. 

If the order icon is selected, the buyer is then directed to an order web page 380, 
as shown in Fig. 8. This page references the offer in which the buyer is interested. Here 
the buyer enters information required by the seller to fulfill the order. Such information 
includes: the buyers purchase order number 385, the quantity required 390, product 
options 345, if available, and billing and shipping information 395 (Fig. 9). Upon 
entering an order quantity, the system can prompt the buyer with a message alerting the 
buyer of an additional discount if the order quantity is increased. Such a prompt can also 
appear when the buyer is ready to confirm his/her order. The prompt can include 'yes' 
and 'no' icons so that if the buyer chooses 'yes', the system will automatically increase 
the buyer's order quantity and calculate the new unit price and overall price. If the buyer 
chooses 'no', the prompt will disappear and the buyer can continue with the order 
process. Furthermore, system prompts, such as this one, can be turned on or off 
according to the buyer's preferences.. 

The order page also contains an entry field 400 for a coupon or discount code. 
These codes are uniquely recorded by the system, thus providing that the buyer will not 
use the coupon or discount more than intended. Coupons or discounts can expire based 
on the number of times used, the date, and/or the order quantity. The system also 
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supports an accruing discount function. This allows sellers to offer automatic discounts 
to buyers who achieve purchasing milestones. The number of units purchased, total 
dollar volume, total orders placed, and/or total time spent buying online can specify these 
milestones. Similarly, an entry field 405 for a gift certificate or merchandise credit code 
is provided on the order page (Fig. 9). If the buyer does not wish to use the entire gift 
certificate or merchandise credit amount for the order, the buyer can specify the dollar 
amount that he/she wishes to use for the order. Based upon the current product price, the 
quantity ordered, what options are selected, and whether any discounts or coupons have 
been used, the total price field 410 will automatically populate with the buyer's total 
order price. The buyer can also add any additional instructions, including shipping 
instructions, for the seller. 

Once the buyer has completed the order entry, the buyer selects a 'continue' icon 
415. At this point, if the system determines that the buyer is not logged in, the system 
will require the buyer enter a login name and password, or alternatively, complete a 
registration process, such as that shown in Fig. 10. In the present example, the 
registration form 420 requests that the buyer enter the following information: buyer 
name; address; primary contact person; phone; fax; e-mail; short description of company; 
preferred login user name; and preferred password. With respect to the user name and 
password, the processing unit 64 is configured to determine whether the selected user 
name and password combination are available and, if not, to prompt the buyer to enter a 
new user name and password until an available combination is selected. 

If the buyer is registered and logged into the system, he/she will be directed to an 
order confirmation page (not shown). Here the details of the order are shown and the 
buyer has the option of confirming, modifying, or canceling the order. If the buyer 
confirms, the order is placed with the seller or the order is sent to a shopping cart. 
Shopping carts can be seller specific. Thus, the buyer can have more than one shopping 
cart active simultaneously. It is to be appreciated that shopping carts can also be 
organized by product category. Moreover, the buyer can only have one shopping cart 
active that contains all orders made by the buyer. Shopping carts will typically be 
emptied once a buyer logs out of the system. However, a buyer has the option of saving 
the shopping cart for later verification. While orders are active within a shopping cart, 
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the deal room can show the order quantity as on hold. Line items within the shopping 
cart based upon offers that have already closed will be considered invalid and ignored by 
the system. A shopping cart can also be created to save quotes received from a seller. 

However, the system can determine that the order cannot be confirmed. An alert 
system can be employed to notify the buyer that the order, as placed, exceeds the buyer's 
authority. This can occur if the buyer is configured within the system to have limited 
purchasing authority. For instance, the buyer may only be permitted to order specified 
products, to remain within an account spending limit, and/or to not exceed a certain dollar 
amount per order. The buyer's supervisor, the seller, or any other user with appropriate 
authority can place such limits. The system can automatically cancel the order, alert the 
buyer to edit the order, or to forward the order to the seller or a supervisor for 
authorization if the buyer exceeds his authority. If the order is awaiting authorization, the 
system will hold the order for a predetermined time period. Thus, the quantity available 
will be reduced for other buyers. The other buyers may be aware of the quantity being 
held, but they will not have access to the identity of the buyer for whom the product is 
being held. If the order is cancelled, the hold quantity is released and made available 
again to the other buyers. 

Regarding Fig. 12, although the present invention has been largely described 
within the context of a seller sponsored deal room (Fig. 1 1), it is to be appreciated that a 
buyer or buyers can sponsor a deal room to aggregate purchasing goods/services from a 
plurality of sellers. For example, a large corporate buyer can employ the present 
invention to create a deal room where a plurality of sellers can assemble to aggregate 
selling of specific goods and/or services that the buyer desires. Such a transaction 
facilitates the buyer satisfying purchase requirements in one forum and to coordinate 
deliver of goods/services. Furthermore, such a system facilitates sellers making sales to 
the buyer, which but for the sellers being able to aggregate the buyer may not have dealt 
with the individual seller because of insufficient capacity to meet the buyers needs. The 
subject specification describes exemplary systems and interfaces for implementing the 
subject invention, and therefore further discussion thereto is omitted for sake of brevity. 
However, it is to be appreciated that one skilled in the art based on the above discussion 
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regarding seller sponsored deal rooms/transactions could apply such teachings to 
implement the aforementioned buyer sponsored deal room/transaction. 

Regarding Fig. 1 3, although many aspect of the present invention have been 
largely described within the context of a seller sponsored deal room/transaction; it is to be 
appreciated that buyers and sellers can concurrently sponsor a deal room/transaction to 
aggregate selling of and purchasing of goods/services by a plurality of sellers and buyers 
respectively. For example, a multiple sellers and buyers can employ the present 
invention to create a deal room/transaction forum where a plurality of sellers and buyers 
can assemble to aggregate selling and buying of specific goods and/or services that the 
sellers wish to sell and the buyers desire to purchase. Such a transaction forum creates 
great efficiencies with respect to purchase price and/or selling quantity of particular 
goods/services. For example, in such a forum dedicated to the selling and purchasing of 
a specific product/service, sellers can assemble to compete for the sale of their respective 
product/service, which leads to pricing efficiencies. Buyers can assemble in such a 
forum to aggregate buying power in order to negotiate good prices and close deals. 
Sellers on the other hand can also aggregate to meet the needs of a large buying block. 
The subject specification describes exemplary systems and interfaces for implementing 
the subject invention, and therefore further discussion thereto is omitted for sake of 
brevity. However, it is to be appreciated that one skilled in the art based on the above 
discussion regarding seller sponsored deal rooms/transactions could apply such teachings 
to implement the aforementioned buyer sponsored deal room/transaction. 

The users and groups module is capable of storing users, groups, and their details, 
such as demographic and marketing information. For example, a buyer is presented with 
a catalog item to determine whether the buyer would be interested in purchasing that 
item, and if so, when they would next need the item and at what quantity. This 
information could then be used to suggest or automatically create aggregate or single 
offers. Users are virtual representations of the physical users of the system and/or remote 
systems, such as corporate purchasing servers or sales-processing servers. Groups are 
collections of users with specific system roles and/or rights. For example, a seller group 
can be granted the right to manage a particular access group and a buyer group can be 
granted access to a particular set of offers and the right to place orders on particular 
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products. Furthermore, groups can be offered different pricing structures and/or product 
quantities than individual users for a particular product. Groups can be contained within 
other groups, thus creating parent-child relationships. In these relationships, child groups 
inherit access permissions from their respective parent groups. The system host or 
administrator, the seller, or the individuals within the group can determine the makeup of 
the groups. Although the descriptions and examples herein commonly refer to 
transactions between an individual buyer and an individual seller, it is to be appreciated 
that such transactions can also occur between one buyer and a group of sellers, a group of 
buyers and a group of sellers, or a group of buyers and a group of sellers. 

Both users and groups are identified by a login name and password, which are 
chosen by the users and groups upon registration. Passwords can be stored using MD5 
encryption. MD5 uses one-way functions rendering it impossible to generate the 
password from knowing only the MD5 hash of the password. Therefore, users and 
groups will be prompted to choose a question and answer pair that will be used to identify 
a user or group in the event that the password is forgotten. Users and groups can choose 
to associate identifying characteristics to their login identity, such as a company name, 
shipping address, billing address, company logo, and/or biography. Some or all of this 
information can be required if the user and/or group chooses to buy and/or sell a product. 

The access control module allows item creators to specify a set of rules, or 
permissions, as to who can access, modify and/or use the items, wherein the term item is 
used to denote categories, products, offers, etc. Read permissions allow users or groups 
to see, but not edit, item information. Edit permissions allows users the ability to make 
changes to the item, as well as, to the access control information relating to that item. 
Relate permissions are used to give a user the ability to create parent/child relationships 
among items; for example, the ability to create a derived product, an offer, or to place a 
product in a category. Place order permissions enable one to place an order on an offer or 
to use a line of credit/account to place an order. System administrators, or other similarly 
privileged users, have override permissions, which enable them to make modifications 
without being subject to edit rules. Override permissions can be global or specific. 
Global override permissions enable one to override all edit rules anywhere on the system, 
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while specific override permissions enable one to modify data pertaining to specified, 
limited areas of the system. 

The messaging module includes the ability for the system to communicate with 
users and other integrated systems. Users are notified of any change that occurs in an 
offer that they are involved in, such as a price change, an opportunity for further discount, 
change in shipping terms, and/or when the offer has been closed. Users can also request 
to be notified of similar changes in offers that they are interested in but have not yet 
participated. Likewise, users can request to be notified if any activity occurs on a 
particular product or product category, such as an additional options available for a 
product, new products offered within the category, new open offers, RFQs, RFOs, RFPs, 
and/or a price changes. Messages can also be sent regarding important changes to the 
system in general. Furthermore, this module contains the ability to turn messages off for 
the entire system, individual users, groups, access points, and/or remote systems. The 
notification and messaging system is also integrated within other modules. 

Messages can be sent through email, fax, mobile devices, instant messages, 
bulletin boards, and/or through a user's homepage. An example of a user's homepage 
450 is shown in Fig. 14. The page 450 includes a seller section 455 where the user 
selects what information he would like to see about a seller, for example, total product 
offerings, product offerings within a specific category, and any open offers. A product 
categories section 460 can also be included on the web page. Here, a user can see 
whether any products or product categories that have been added, modified, or deleted in 
the system. The user's homepage 450 also includes a news section 465 in which the user 
can view news headlines and/or market conditions in any specified industries. This 
section can also inform the user about what has changed on the system since the user was 
last logged on. For example, the user can see any new buyers and/or sellers that have 
joined the system, any new offers that have been opened in his area of interest, and any 
changes that have occurred in the user's own open offers. The homepage 450 can be 
configured to allow the user to monitor all open offers in which he/she is participating 
470 and/or all open offers in which he/she has selected to watch 475. The web page also 
contains a search field 480, which enables the user to search the system for information, 
such as a particular seller, buyer, product, or offer. For example, a buyer can search for 
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all open offers which meet the buyer's criteria. The results can be arranged in order of 
cost, shipping date, offer close date, etc. A hyperlink 485 is provided to the user's 
account information page (not shown). The account information page allows the user to 
view and/or modify passwords, shipping and billing addresses, methods of payment, etc. 
Another hyperlink 490 is provided to the user's history page (not shown). Here the user 
can view all past orders, RFQs, RFOs, RFPs, etc. It is to be appreciated that this is just 
one example of a homepage and that many variations can exist since each homepage is 
customized to provide information relevant to the particular user. 

The terms and conditions module handles the entry, storage, and acceptance of 
system-wide, access point sponsor, and seller terms and conditions. Terms and 
conditions can be created by using a system template or through free text entry; and relate 
to the terms governing the sale of the product according to which both the buyer and 
seller are willing to conduct business. System-wide terms and conditions are those that 
apply to, and must be accepted by, all users and groups participating in the system. It is 
possible to have one set, more than one set, or no sets of active system-wide terms and 
conditions. Access point sponsors can require users of their access points to agree to one 
or more set of terms and conditions. Sellers can require buyers, which wish to purchase 
from them, to accept certain terms and conditions. Sellers can have different sets of 
terms and conditions for different buyers. For example, a seller can have stricter set of 
terms and conditions for first time buyers than for those which the seller has maintained a 
long relationship. Likewise, any other user requiring another user to accept certain terms 
and conditions can tailor the terms and conditions to apply to that particular user. 
Moreover, buyers can also require seller to accept the buyer's terms and conditions prior 
to purchasing. The terms and conditions agreed to between parties are stored in the 
system and can be modified as necessary. 

The blanket pricing module allows a seller to provide discount pricing to 
individual buyers and/or groups of buyers for one or more items. The system always 
defaults to the lowest price available to a buyer when determining the final order cost. 
Thus, although buyers can have multiple blanket prices for a particular product, the 
lowest price will always take precedence. For example, a 1 5% discount can yield a lower 
overall cost than a $5 off discount in a particular order. Blanket pricing can be indefinite, 
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dynamic, or fixed. Indefinite blanket pricing is in effect immediately after it is entered or 
beginning at a specified start date and will affect all future orders until the blanket price is 
manually revoked. A pricing sheet or equation is employed for dynamic blanket pricing. 
Here, the price can increase or decrease depending upon the buyers purchasing activities. 
Dynamic blanket pricing can apply to one product or an entire family of products. Fixed 
blanket pricing gives sellers the option of setting a start date and end date for which the 
blanket price is effective. Alternatively, the blanket price can only be effective for a 
specified quantity of products. 

Blanket prices can be specified as a percentage or as a specified dollar amount to 
be discounted from the final price. Sellers can also use stepped blanket pricing. This 
allows the sellers to provide the buyers with a pricing sheet that details changes in the 
blanket prices with order quantity and/or time. The system has the ability to recommend 
pricing strategies for sellers to construct better blanket pricing. These strategies include 
calculation routines that use a maximum discount percentage, or fixed cost, to create a 
step structure such that when the buyer has purchased the required amount, the average 
price per unit is at the desired level. For example, a seller could offer a blanket price of 
$1 5/unit with a commitment of 5000 units. Rather than assuming that the purchasing 
commitment will be met, the seller could structure the pricing as $20 for the first 2000 
units, $18 for the next 1000 units, and finally, $8.50 for the remaining 2000 units. Thus, 
if the buyer purchases the entire lot, the average price of $1 5/unit is attained; otherwise 
the buyer simply receives a tiered discount. 

The system recognizes relationships between products. A manufacturer can 
identify a bill of materials for a product and configure the system so that an order for a 
product will, in turn, trigger orders for all of the product's component parts. 
Alternatively, the system can present order recommendations or place RFOs or RFQs 
instead of actually placing the order. Byproduct relationships are also recognized by the 
system. Here, the system automatically creates or suggests a byproducts offer when the 
primary product is ordered. For example, if an order for brass fittings is placed, the 
system will put out an offer for brass scrap metal produced by the machining process. As 
more orders are placed, the offer quantity increases. Furthermore, the system can 
recognize when two different products produce the same byproduct. For example, if an 
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order for brass valves is placed, instead of creating a new offer for brass scrap metal, the 
system will increase the quantity of the brass scrap metal offer that has already been 
placed as a result of the order for brass fittings. 

The system also recognizes products that share certain features and/or 
characteristics. Thus, when opening an offer for a particular product, a seller can be 
alerted of the manufacturing efficiencies available if he also opens an offer for other 
family members of that product. These manufacturing efficiencies can be based upon 
decreases in machine change over time when switching from one product to another, 
decreases in tooling and/or raw material cost, and/or increases in operator efficiencies. 
Also, products and/or product families can be shared between one or more sellers. The 
sellers could be two distributors of the same product, a manufacturer and a distributor of 
the same product, two manufacturers of the same product and/or one of the 
aforementioned combinations of related products that can be readily substituted. Thus, if 
one seller does not have the capacity for a buyer's requirements, the system can suggest 
or automatically split the buyer's order quantity among the different sellers. 

Aggregation of shipping costs can be achieved with the logistics module. Thus, 
on an open offer, buyers can receive the benefits of product aggregation, as well as the 
benefits of shipping aggregation. Buyers and sellers can choose to share shipping costs 
with those who share single departure and arrival points and/or with those who share a 
common truck route. Truck filling based aggregation uses the truck dimensions to fill the 
truck to a specified percentage capacity. A pricing sheet, or pricing equation, will be 
used to determine the savings as different capacity levels are achieved. Moreover, the 
system can determine whether any buyers or sellers within a specified area are having 
product shipped on the same day. Such area-based truck sharing supports both multiple 
load and delivery points. The system can further divide the shipping area into zip codes. 
Rules are then used to determine how to best fit the items on the trucks. Furthermore, 
custom truck routes can be created by the system in order to achieve the most efficient 
shipping schedule, which, in turn, leads to significant cost benefits. For example, a 
preliminary route is provided with list of intervening zip codes. The system then 
searches for orders that can be picked up or delivered using that route. The system can 
also modify the route based on other orders as long as the modified route will not 
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detrimentally affect the overall shipping schedule. This module can be integrated with 
shipping companies and can, alternatively, be available as a separate service. 

The RFQ and RFO functions are designed to drive orders towards aggregation 
whenever possible. A buyer user, agent, or process initiates a RFQ and/or a RFO to 
predetermined sellers or all sellers of a particular product, specifying an existing product 
or a description of what is desired. If a specific product is requested by the buyer through 
a RFQ and/or RFO to a seller, other than the seller of the specified product, that seller 
will only receive a general description of the product. The RFQ and/or RFO can also 
include other buyer requirements, such as, quantity, cost range, delivery date or date 
range, and/or one or more delivery points. Upon receiving the RFQ and/or RFO the 
seller can accept the request and reply with a corresponding quote and/or offer, or the 
seller can reject the request. If the request is rejected, the seller has the option of 
notifying the buyer which requirements the seller was not able to meet, and further, make 
reasonable counter-offers to the buyer. Thus, the buyer and seller have the opportunity of 
negotiating for a successful transaction. As an alternative to a RFQ, the buyer can 
employ a quote generator to view various offer and option choices. The quote generator 
can return the same information as a formal RFQ but may not be binding upon a seller 
unless that seller confirms the quote. 

An RFP allows a buyer user, agent, or process to request product from one or 
more sellers. The request can be for a one-time offering of the particular product or can 
be for a regular listing of the product. The RFP can detail which characteristics of the 
product the buyer is interested in, which can lead to a seller suggesting a similar product 
that the seller currently offers through the system. The RFP can also detail information 
such as, how often the buyer needs the product, in what quantities, what price range, 
whether any options are desired, and the next need date. 

The invoicing module is utilized to store and update account information, create 
transaction summaries and invoices, and to process account status-dependant queries, 
such as those necessary for account spending limits. System-to-party invoices, such as 
transactions fees and recurring fees (e.g., the monthly hosting cost), can be automatically 
created through this module. The transaction fees are structured as per-transaction fees, 
fixed percentage fees, or variable fees. The per-transaction fee is set so that a user is 
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charged a predetermined fee for each transaction, regardless of the total order cost. The 
fixed percentage fee is based on the total order cost for each transaction. The variable fee 
employs a pricing sheet to specify different transaction fees at different order volumes. 
These fees can be applied against a seller, a buyer, or both. Recurring fees are initialized 
to charge a user a predetermined amount and a regular frequency. The ability to set fee 
start dates, end dates, and waivers are also provided by the system. 

The invoicing module also manages system-to-system invoicing and party-to- 
party invoicing. System-to-system invoicing allows the system to notify integration 
partners of the amounts that they or those who access the system through them owe. 
Party-to-party invoicing allows sellers and buyers to manage their account online, 
including account spending limits. If a buyer places an order, or any other fee-required 
transaction, and does not maintain an account with the system or the transaction exceeds 
the buyers spending limit, the buyer will be prompted to pay for the transaction through a 
credit card, electronic check, or other immediate-approved method. If such payment 
cannot be secured, the transaction will be cancelled. An account can be charged over- 
limit fees, late fees, interest, etc. at the discretion of the account lender. The invoicing 
module also provides interfaces for the system users to make payments and the account 
lenders to post payment receipts. 

The agents module employs historical data and user input data to create and/or 
suggest various functions to buyers and sellers. Buyers and sellers can create customized 
agents based on their particular needs or use system default agents. Furthermore, agents 
can be turned on and off individually or as a group. A seller agent assists a seller 
maximize production efficiencies. The seller agent system uses information from the 
seller's previous offers and orders, such as the total capacity of product that went 
unpurchased for each open offer, to determine a price curve that is most likely to 
maximize profits for the seller. This agent also recommends the amount of time the seller 
should leave his offer open, the quantities the seller should offer, what options the seller 
should offer, the option costs, the shipping increments, and any other information 
necessary to allow for the greatest efficiencies and profits. Moreover, the seller can 
receive recommendations on which products should be offered as an aggregate offer and 
which products should be offered as a single offer. Offers can be automatically created 
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for a seller on a regularly scheduled basis or alternatively, the seller agent can use the 
seller's inventory levels, forecast information, and open orders to determine when the 
next offer should be created. The seller can require that the offer be marked for review 
and manual activation; or the seller can allow the agent to create and activate the order 
without intervention. 

The agent can also look at and make suggestions based on buying trends for a 
particular product. For example, the agent recognizes that one particular buyer always 
buys a product when it falls below a certain price. The agent can then recommend to the 
seller that the seller enter into a NTE contract price with that buyer, thus increasing the 
likelihood of more orders from that buyer. Furthermore, the system can track each time a 
buyer reviews a particular product and recommend a pricing strategy for the buyer with 
respect to that product. For example, a buyer reviews the price of a product at price m, 
price n, and price o, and places an order at price o. This information is stored whenever 
the buyer returns and looks at the product. Over time, the system will calculate every 
price the buyer ignored and accepted, and determine a customized curve for that buyer. 
The seller can instruct the system to reflect price increase a certain amount above the 
usually ordered price, or lock in a price at that point as well, creating a contract price 
variation in real time. As an additional example, the system recognizes that a buyer 
reviews a particular product three times without placing an order. The system, then, 
offers a coupon and/or discount to the buyer based upon such traffic patterns and 
products viewed in order to entice the buyer to purchase. 

The seller agent can also be employed to analyze any open deal room activities. 
The seller can see the number of buyers that have entered the deal room and of those 
buyers, how many have actually placed an order. Thus, the seller agent can suggest how 
the seller can modify aspects of an open deal room in response to buyer activity. The 
seller can choose to close the deal room early, modify the available capacity, open a new 
deal room for the same product at a different pricing structure, or any other modification 
which allows the seller to best allocate his fixed resources. Seller agents can also display 
the seller's relative market share versus their competition with respect to a particular 
category, subcategory, or product in real time. Thus, the seller can choose to modify one 
or more open offers in order to increase his market share percentage. 
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Moreover, the seller agent can be used to suggest and/or create the seller's 
production and/or manufacturing schedule. The agent will take into consideration 
historical set-up times between different products (for example, how long it takes to 
change over a machine when switching from product A to product B as opposed to 
switching from product A to product C), run efficiencies associated with each machine, 
percent scrap associated with each machine, percent downtime for a machine, scheduled 
maintenance times, operator efficiencies, and any other applicable data, to determine 
which machines the products should run on and in what order. The agent can also 
recommend the best machine operator for the job and on which shifts the job should run. 
Moreover, the agent can use the seller's historical data and MRP information to forecast 
the seller's manufacturing plan by balancing anticipated demand with available capacity. 

The seller agent is also capable of interacting with a buyer. Upon request from a 
buyer, the agent can create blanket prices, new aggregate offers, new single offers, add an 
order to existing offers, and/or reply to RFQs, RFOs, and RFPs. The goal of the agent is 
still to achieve the highest profit margin and manufacturing efficiencies for the seller. If 
the buyer terms and the seller terms are conflicting, the details will be forwarded to the 
seller for manual review and/or inform the buyer that the terms cannot be accepted. 
Shipping costs, carrying costs, transaction fees, and any other fees related to an offer 
and/or order are considered by the seller agent. Rewards and/or penalties are created 
based on time, the number of buyers on an offer to date, the quantity of product sold, the 
current price, and the number of cancellations, if any. The rewards can be in the form of 
a percent discount, flat discount, or bonus items. Penalties can be in the form of a percent 
markup, flat markup, or one time charge, and can be automatically given to any buyer 
that cancels an order or reduces the order quantity. 

A buyer agent considers the needs of a buyer and assists in finding the best buy 
for a particular product. This agent looks at previous offer and order history for all 
sellers or specified sellers of a product and considers past offer percent aggregation, final 
price achieved, carrying cost vs. aggregation savings, transaction fees, any discounts that 
can be applied to a particular seller, and any other applicable factor to make a suggestion 
as to how and where the buyer should place an order. Current market information is also 
taken into consideration. Thus, the agent provides a comparison between the fair market 
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value for a product and a reasonably anticipated price that can be achieved through the 
aggregation system. 

Similar to the seller agent, the buyer agent interacts with sellers to create an 
aggregate order, a single order, a RFQ, a RFO, and/or a RFP. The agent can 
automatically place an order or provide a suggested order to the buyer and wait for 
manual interaction. The buyer can set up an automated process to place recurring orders, 
specifying maximum costs, quantity, required receipt dates, etc. The agent can also be 
configured to automatically place an order when the inventory level of a buyer falls 
below a predetermined level. Furthermore, the agent has the ability to analyze the 
buyer's production schedule and determine which products are needed and when in order 
to achieve the best buying opportunities. Shipping costs, carrying costs, lot sizes, seller 
quality, potential benefits of ordering early as opposed to waiting, and any other factor 
important in the buyer's decision making process are also considered by the buyer agent. 
The seller and buyer agents described above can perform the same functions with respect 
to a group of sellers or a group of buyers. 

Agents are also used to assist the system host or administrator. An association 
agent is employed to analyze buyer behavior, including searches performed, orders 
placed, RFOs, RFQs, RFPs, and other similar actions to improve the product category 
structure. The association agent also generates aggregate sales information for deal 
rooms, categories, subcategories, products, etc. A content processing agent provides 
methods that intelligently associates content with products, categories, offers, and/or 
access points. This agent analyzes data on buyer and seller demographics, previous 
purchases, and other user behavior, as described above. A publisher/portal agent 
interfaces with the content processing agent and either suggests or automatically 
processes the addition and/or removal of content on the system. 

All system users can make use of an exchange agent as it is concerned with 
activities such as, automation of billing, payment posting, and registration. This agent is 
also capable of overseeing the entire exchange process to identify any problem areas or 
system errors. For example, the exchange agent monitors deal room activities and if any 
manual intervention is necessary to troubleshoot the deal room, the exchange agent alerts 
the system administrator, host or deal room creator. 
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Although many aspect of the present invention have been largely described within 
the context of buying and selling goods; it is to be appreciated that buyers and sellers can 
sponsor deal rooms/transactions to aggregate selling of and purchasing of services, such 
as broadband, data storage, cell phones, electricity, gas, training programs, etc. For 
5 example, a service provider can contract with a group of buyers over a period of time to 
realize cost efficiencies tied to their usage and/or consumption. A pricing structure can 
be based upon time (seconds, days, months, years, etc.) and/or the quantity of usage 
and/or consumption over the specified time period and will be displayed in a deal room, 
similar to the examples above. A buyer can then visit the deal room at any point in time 
1 0 to track usage and/or consumption and also, view the current price, or billing schedule in 
,71 real time. The buyer can view his/her individual usage and/or consumption, as well as, 

55 s ! the usage and/or consumption of the entire buying group for that particular service. 

fU 

FU Furthermore, as above, the curves can vary for different buyers, based upon items such as 

S3 

03 rebate schedules, discounts, amount of usage and/or consumption, and length of contract 

1 5 between the buyer and the seller. 

The system, as described above, is functional internationally. Thus, conversions 
are provided by the system for language, currency, units of measure, time and date, etc. in 
yj order to comply with a particular region's standard. Users can have the option of 
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choosing which standards they prefer when registering with the system. 

20 With reference to Fig. 1 5, an exemplary system 500 for implementing the 

invention includes a conventional personal or server computer 5 1 0, including a 
processing unit 520, a system memory 530, and a system bus 540 that couples various 
system components including the system memory 530 to the processing unit 520. The 
processing unit 520 can be any of various commercially available processors. Dual 

25 microprocessors and other multi -processor architectures also can be used as the 
processing unit 520. 

The system bus 540 can be any of several types of bus structure including a 
memory bus or memory controller, a peripheral bus, and a local bus using any of a 
variety of commercially available bus architectures. The system memory includes read 

30 only memory (ROM) 550 and random access memory (RAM) 560. A basic input/output 
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system (BIOS), containing the basic routines that help to transfer information between 
elements within the computer 510, such as during start-up, is stored in ROM 550. 
The computer 510 further includes a hard disk drive 570, a magnetic disk drive 580, e.g., 
to read from or write to a removable disk 590, and an optical disk drive 600, e.g., for 
reading a CD-ROM disk 61 0 or to read from or write to other optical media. The hard 
disk drive 570, magnetic disk drive 580, and optical disk drive 600 are connected to the 
system bus 540 by a hard disk drive interface 620, a magnetic disk drive interface 630, 
and an optical drive interface 640, respectively. The drives and their associated 
computer-readable media provide nonvolatile storage of data, data structures, computer- 
executable instructions, etc. for the server computer 510. Although the description of 
computer-readable media above refers to a hard disk, a removable magnetic disk and a 
CD, it should be appreciated by those skilled in the art that other types of media which 
are readable by a computer, such as magnetic cassettes, flash memory cards, digital video 
disks, Bernoulli cartridges, and the like, can also be used in the exemplary operating 
environment. A number of program modules can be stored in the drives and RAM 560, 
including an operating system 650, one or more application programs 660, other program 
modules 670, and program data 680. 

A user interface provides an interface through which the central server 25 can be 
directly programmed or accessed. The user interface can, for example, be an 
alphanumeric keyboard 690 and mouse 700. Other input devices (not shown) can include 
a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other 
input devices are often connected to the processing unit 520 through a serial port 
interface 7 1 0 that is coupled to the system bus 540, but can be connected by other 
interfaces (not shown), such as a parallel port, game port or a universal serial bus (USB). 
A monitor 720 or other type of display device is also connected to the system bus 540 via 
an interface, such as a video adapter 730. In addition to the monitor 720, computers 
typically include other peripheral output devices (not shown), such as speakers and 
printers. 

The computer 510 can operate in a networked environment using logical 
connections to one or more remote computers, such as a remote server or client computer 
740. The remote computer 740 can be a workstation, a server computer, a router, a peer 
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device or other common network node, and typically includes many or all of the elements 
described relative to the computer 510, although only a memory storage device 750 has 
been illustrated in Fig. 1 5. The logical connections depicted in Fig. 1 5 include a local 
area network (LAN) 760 and a wide area network (WAN) 770. Such networking 
environments are commonplace in offices, enterprise-wide computer networks, intranets 
and the Internet. 

When used in a LAN networking environment, the computer 510 is connected to 
the local network 760 through a network interface or adapter 780. When used in a WAN 
networking environment, the server computer 520 typically includes a modem 790, or is 
connected to a communications server on the LAN 760, or has other means for 
establishing communications over the wide area network 770, such as the Internet. The 
modem 790, which can be internal or external, is connected to the system bus 540 via the 
serial port interface 710. In a networked environment, program modules 670 depicted 
relative to the computer 51 0, or portions thereof, can be stored in the remote memory 
storage device 750. It will be appreciated that the network connections shown are 
exemplary and other means of establishing a communications link between the computers 
can be used. 

The present invention may be implemented via object oriented programming 
techniques. In this case each component of the system, could be an object in a software 
routine or a component within an object. Object oriented programming shifts the 
emphasis of software development away from function decomposition and towards the 
recognition of units of software called "objects" which encapsulate both data and 
functions. Object Oriented Programming (OOP) objects are software entities comprising 
data structures and operations on data. Together, these elements enable objects to model 
virtually any real-world entity in terms of its characteristics, represented by its data 
elements, and its behavior represented by its data manipulation functions. In this way, 
objects can model concrete things like people and computers, and they can model abstract 
concepts like numbers or geometrical concepts. 

The benefit of object technology arises out of three basic principles: 
encapsulation, polymorphism and inheritance. Objects hide or encapsulate the internal 
structure of their data and the algorithms by which their functions work. Instead of 
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exposing these implementation details, objects present interfaces that represent their 
abstractions cleanly with no extraneous information. Polymorphism takes encapsulation 
one step further - the idea being many shapes, one interface. A software component can 
make a request of another component without knowing exactly what that component is. 
The component that receives the request interprets it and figures out according to its 
variables and data how to execute the request. The third principle is inheritance, which 
allows developers to reuse pre-existing design and code. This capability allows 
developers to avoid creating software from scratch. Rather, through inheritance, 
developers derive subclasses that inherit behaviors, which the developer then customizes 
to meet particular needs. 

In particular, an object includes, and is characterized by, a set of data (e.g., 
attributes) and a set of operations (e.g., methods), that can operate on the data. Generally, 
an object's data is ideally changed only through the operation of the object's methods. 
Methods in an object are invoked by passing a message to the object (e.g., message 
passing). The message specifies a method name and an argument list. When the object 
receives the message, code associated with the named method is executed with the formal 
parameters of the method bound to the corresponding values in the argument list. 
Methods and message passing in OOP are analogous to procedures and procedure calls in 
procedure-oriented software environments. 

However, while procedures operate to modify and return passed parameters, 
methods operate to modify the internal state of the associated objects (by modifying the 
data contained therein). The combination of data and methods in objects is called 
encapsulation. Encapsulation provides for the state of an object to only be changed by 
well-defined methods associated with the object. When the behavior of an object is 
confined to such well-defined locations and interfaces, changes (e.g., code modifications) 
in the object will have minimal impact on the other objects and elements in the system. 

Each object is an instance of some class. A class includes a set of data attributes 
plus a set of allowable operations (e.g., methods) on the data attributes. As mentioned 
above, OOP supports inheritance - a class (called a subclass) may be derived from 
another class (called a base class, parent class, etc.), where the subclass inherits the data 
attributes and methods of the base class. The subclass may specialize the base class by 
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adding code which overrides the data and/or methods of the base class, or which adds 
new data attributes and methods. Thus, inheritance represents a mechanism by which 
abstractions are made increasingly concrete as subclasses are created for greater levels of 
specialization. 

The present invention can employ abstract classes, which are designs of sets of 
objects that collaborate to carry out a set of responsibilities. Frameworks are essentially 
groups of interconnected objects and classes that provide a prefabricated structure for a 
working application. It should also be appreciated that the PCM and the shared memory 
components could be implemented utilizing hardware and/or software, and all such 
variations are intended to fall within the appended claims included herein. 

According to an exemplary aspect of the present invention, Java and CORBA 
(Common Object Request Broker Architecture) are employed to carry out the present 
invention. Java is an object-oriented, distributed, secure, architecture neutral language. 
Java provides for object-oriented design, which facilitates the clean definition of 
interfaces and makes it possible to provide reusable "software ICs." Java has an 
extensive library of routines for copying easily with TCP/IP protocols like HTTP and 
FTP. Java applications can open and access objects across a network via URLs with the 
same ease to which programmers are accustomed to accessing a local file system. 

Furthermore, Java utilizes "references" in place of a pointer model and so 
eliminates the possibility of overwriting memory and corrupting data. Instead of pointer 
arithmetic that is employed in many conventional systems, the Java 'Virtual machine" 
mediates access to Java objects (attributes and methods) in a type-safe way. In addition, it 
is not possible to turn an arbitrary integer into a reference by casting (as would be the 
case in C and C++ programs). In so doing, Java enables the construction of virus-free, 
tamper-free systems. The changes to the semantics of references make it virtually 
impossible for applications to forge access to data structures or to access private data in 
objects that they do not have access to. As a result, most activities of viruses are 
precluded from corrupting a Java system. 

Java affords for the support of applications on networks. Networks are composed 
of a variety of systems with a variety of CPU and operating system architectures. To 
enable a Java application to execute anywhere on the network, a compiler generates an 
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architecture neutral object file format - the compiled code is executable on many 
processors, given the presence of the Java runtime system. Thus, Java is useful not only 
for networks but also for single system software distribution. In the present personal 
computer market, application writers have to produce versions of their applications that 
are compatible with the IBM PC and with the Apple Macintosh. However, with Java, the 
same version of the application runs on all platforms. The Java compiler accomplishes 
this by generating byte code instructions that have nothing to do with particular computer 
architecture. Rather, they are designed to be both easy to interpret on any machine and 
easily translated into native machine code on the fly. 

Being architecture neutral, the "implementation dependent" aspects of the system 
are reduced or eliminated. The Java virtual machine (VM) can execute Java byte codes 
directly on any machine to which the VM has been ported. Since linking is a more 
incremental and lightweight process, the development process can be much more rapid 
and exploratory. As part of the byte code stream, more compile-time information is 
carried over and available at runtime. 

Thus, the use of Java in the present invention provides a server to send programs 
over the network as easily as traditional servers send data. These programs can display 
and manipulate data on a client computer. The present invention through the use of Java 
supports execution on multiple platforms. That is the same programs can be run on 
substantially all computers - the same Java program can work on a Macintosh, a 
Windows machine, a Sun workstation, etc. To effect such multi-platform support, a 
network interface and a network browser (not shown) such as Netscape Navigator or 
Microsoft Internet Explorer may be used in at least one aspect of the present invention. It 
should be appreciated, however, that a Java stand-alone application might be constructed 
to achieve a substantially equivalent result. Although the present invention is described 
with respect to employing Java, it will be appreciated that any suitable programming 
language may be employed to carry out the present invention. 

An Internet browser (e.g., Netscape, Microsoft Internet Explorer) is held within 
the memory of the client computer. The Internet Explorer enables a user to explore the 
Internet and view documents from the Internet. The Internet Explorer may include client 
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programs for protocol handlers for different Internet protocols (e.g., HTTP, FTP and 
Gopher) to facilitate browsing using different protocols. 

It is to be appreciated that any programming methodology and/or computer 
architecture suitable for carrying out the present invention may be employed and are 
intended to fall within the scope of the hereto appended claims. 

Although the invention has been shown and described with respect to a certain 
preferred aspect or aspects, equivalent alterations and modifications will occur to others 
skilled in the art upon reading and understanding this specification and the annexed 
drawings. In particular regard to the various functions performed by the above described 
components (systems, assemblies, systems, etc.), the terms used to describe such 
components are intended to correspond, unless otherwise indicated, to any component 
which performs the specified function of the described component (i.e., that is 
functionally equivalent), even though not structurally equivalent to the disclosed structure 
which performs the function in the herein illustrated exemplary aspect or aspects of the 
invention. In addition, while a particular feature of the invention may have been 
described above with respect to only one of several aspects, such feature may be 
combined with one or more other features of the other aspects, as may be desired and 
advantageous for any given or particular application. Furthermore, to the extent that the 
term "includes" is used in either the detailed description or the claims, such term is 
intended to be inclusive in a manner similar to the term "comprising". 
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